註：本篇的專案編號、org id 都已遮罩。發文前記得確認自己的 identifier 沒有裸露在截圖或指令裡。

把 Cloud Run 上的 A2A agent 掛進 Gemini Enterprise 前台，理論上是「註冊一下就好」。我實際做的時候，前半場一小時全部浪費在錯的 app 上。

寫這篇不是為了教註冊步驟，是為了把那一小時省給你。

我做錯了什麼

我用 A 帳號在 Cloud Shell 裡把 agent 註冊到專案 7899…1878 的某個 enterprise app。

user 看的前台則屬於 B 帳號的專案 6474…9189 的另一個 engine。

兩個不同專案的兩個不同 app。agent 當然不會出現。

根本原因是一個很無聊但代價很高的事實：console 的專案選擇器與 Cloud Shell 的 active project 是各自獨立的。 你在 console 上方切了專案，不代表 Cloud Shell 裡的 gcloud config get-value project 跟著變，反之亦然。

多帳號情境會把這個坑放大。我這次是 GE 租戶由一個帳號辦、實作在另一個帳號，兩邊各自都「看起來對」。

我在那一小時做了什麼

依序調了這些欄位，全部無效：

• sharingConfig
• icon
• agentInvocationSpec
• toolSettings.toolDescription

每一個都有合理的假設支撐(權限不對？沒圖示所以不顯示？invocation 設定錯了？)，每一個都值得試。問題是它們全都建立在「我改的是同一個 app」這個沒被驗證的前提上。

正確的診斷順序

事後我把它寫成規則，重點是每一步都是量測，不要先調欄位：

第一步，對專案。 從前台的除錯面板讀 projectNumber，跟你 POST 的 URL 裡的專案編號比對。不同就停手，先搬對地方。

這一步省最多時間，而且只要三十秒。

第二步，diff 欄位。 GET .../agents 把「會顯示的 agent」跟「你的目標 agent」並排比對，看 state、sharingConfig.scope、icon 差在哪。

拿一個已知會動的東西當對照組，比對著文件猜有效得多。

第三步，撈託管端請求日誌。

gcloud logging read 'resource.type="cloud_run_revision" AND resource.labels.service_name="<svc>"' --freshness=20m

這一步回答的問題是：對方到底有沒有往外打？

兩條順手撈到的事實

A2A 不需要跨專案部署。 Cloud Run 服務留在原專案就好，只有註冊 metadata 要建在前台那個 app 底下。我一度以為要把整個服務搬過去。

console 表單按「完成」可能靜靜失敗。 沒有錯誤訊息，就是沒建成功。改用 REST 的 agents.create 重打一次，才拿到真正的錯誤訊息。遇到「按了沒反應」，先試這招。

註冊成功長什麼樣

搬到正確的 app 之後，agent 確實出現在前台清單裡了：ENABLED 狀態、分享範圍 ALL_USERS、有 icon，卡片的 protocolVersion 是 0.2.6，GE 沒有拒絕它。

看起來一切正常。

然後我問它一句話，它回「回答問題時發生錯誤，請稍後再試」。

明天講這個錯誤訊息背後是什麼，以及為什麼那是一堵我搬不動的牆。